Coding weighted angular prediction for intra coding

ABSTRACT

A method and apparatus for decoding JVET video, including receiving a bitstream, and parsing said bitstream to identify a syntax element indicating an intra direction mode to use for generating at least one predictor. The intra direction mode is a first intra direction mode in a plurality of intra direction modes that includes at least one weighted intra direction mode that corresponds to a non-weighted intra direction mode. The syntax element may identify whether to use a non-weighted or weighted intra direction mode to generate the at least one predictor. Thus, the coding unit may be coded in accordance with the at least one generated predictor associated with the selected intra direction mode.

CLAIM OF PRIORITY

This application is a continuation of U.S. patent application Ser. No.15/605,901, filed May 25, 2017, which claims priority under 35 U.S.C. §119(e) from earlier filed U.S. Provisional Patent Application No.62/481,671, filed Apr. 4, 2017, from earlier filed U.S. ProvisionalPatent Application No. 62/481,285, filed Apr. 4, 2017, and from earlierfiled U.S. Provisional Patent Application No. 62/341,210, filed May 25,2016, all of which are hereby incorporated by reference.

TECHNICAL FIELD

The present disclosure relates to the field of video coding,particularly coded weighted angular prediction for intra coding in JVET.

BACKGROUND

The technical improvements in evolving video coding standards illustratethe trend of increasing coding efficiency to enable higher bit-rates,higher resolutions, and better video quality. The Joint VideoExploration Team is developing a new video coding scheme referred to asJVET. Similar to other video coding schemes like HEVC (High EfficiencyVideo Coding), JVET is a block-based hybrid spatial and temporalpredictive coding scheme. However, relative to HEVC, JVET includes manymodifications to bitstream structure, syntax, constraints, and mappingfor the generation of decoded pictures. JVET has been implemented inJoint Exploration Model (JEM) encoders and decoders.

SUMMARY

The present disclosure provides a method of partitioning a video codingblock for JVET, the method comprising receiving a bitstream indicatinghow a coding tree unit was partitioned into coding units according to apartitioning structure that allows nodes to be split according to apartitioning technique, and parsing said bitstream to identify a syntaxelement indicating an intra direction mode to use for generating atleast one predictor. The intra direction mode is a first intra directionmode in a plurality of intra direction modes that includes at least oneweighted intra direction mode that corresponds to a non-weighted intradirection mode. The method further comprises identifying from the syntaxelement whether to use a non-weighted or weighted intra direction modeto generate the at least one predictor, generating the at least onepredictor using the intra direction mode, and coding said coding unit inaccordance with the at least one generated predictor associated with theselected intra direction mode.

The present disclosure also provides an apparatus for coding video datacomprising one or more processors configured to perform the techniquesdisclosed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

Further details of the present invention are explained with the help ofthe attached drawings in which:

FIG. 1 depicts division of a frame into a plurality of Coding Tree Units(CTUs).

FIG. 2 depicts an exemplary partitioning of a CTU into Coding Units(CUs).

FIG. 3 depicts a quadtree plus binary tree (QTBT) representation of FIG.2's CU partitioning.

FIG. 4 depicts a simplified block diagram for CU coding in a JVETencoder.

FIG. 5 depicts possible intra prediction modes for luma components inJVET.

FIG. 6 depicts a simplified block diagram for CU coding in a JVETdecoder.

FIG. 7A depicts an HEVC method of intra prediction, where each intraprediction unit (PU) selects one intra prediction mode to be used.

FIG. 7B depicts a prediction CU being generated from pixels in referenceline.

FIG. 7C illustrates the use of reference samples Rx, in prediction toobtain predicted samples Px,y for a block of size N×N samples.

FIG. 8 depicts an example of multiple line-based intra prediction forJVET intra prediction modes.

FIG. 9 is an example of a weighted parameter table.

FIG. 10 illustrates another example a weighted parameter table.

FIG. 11 depicts an embodiment of a computer system adapted and/orconfigured to process a method of CU coding.

FIG. 12 is a flow diagram that illustrates a method for performing thedisclosed techniques.

FIG. 13 is a high level view of a source device and destination devicethat may incorporate features of the systems and devices describedherein.

DETAILED DESCRIPTION

FIG. 1 depicts division of a frame into a plurality of Coding Tree Units(CTUs) 100. A frame can be an image in a video sequence, which mayinclude a plurality of frames. A frame can include a matrix, or set ofmatrices, with pixel values representing intensity measures in theimage. The pixel values can be defined to represent color and brightnessin full color video coding, where pixels are divided into threechannels. For example, in a YCbCr color space pixels can have a lumavalue, Y, that represents gray level intensity in the image, and twochrominance values, Cb and Cr, that represent the extent to which colordiffers from gray to blue and red. In other embodiments, pixel valuescan be represented with values in different color spaces or models. Theresolution of the video can determine the number of pixels in a frame. Ahigher resolution can mean more pixels and a better definition of theimage, but can also lead to higher bandwidth, storage, and transmissionrequirements.

Frames of a video sequence, or more specifically the coding tree unitswithin each frame, can be encoded and decoded using JVET. JVET is avideo coding scheme being developed by the Joint Video Exploration Team.Versions of JVET have been implemented in JEM (Joint Exploration Model)encoders and decoders. Similar to other video coding schemes like HEVC(High Efficiency Video Coding), JVET is a block-based hybrid spatial andtemporal predictive coding scheme. During coding with JVET, a frame isfirst divided into square blocks called CTUs 100, as shown in FIG. 1.For example, CTUs 100 can be blocks of 128×128 pixels.

FIG. 2 depicts an exemplary partitioning of a CTU 100 into CUs 102,which are the basic units of prediction in coding. Each CTU 100 in aframe can be partitioned into one or more CUs (Coding Units) 102. CUs102 can be used for prediction and transform as described below. UnlikeHEVC, in JVET the CUs 102 can be rectangular or square, and can be codedwithout further partitioning into prediction units or transform units.The CUs 102 can be as large as their root CTUs 100, or be smallersubdivisions of a root CTU 100 as small as 4×4 blocks.

In JVET, a CTU 100 can be partitioned into CUs 102 according to aquadtree plus binary tree (QTBT) scheme in which the CTU 100 can besplit into square blocks according to a quadtree, and those squareblocks can then be split horizontally or vertically according to binarytrees. Parameters can be set to control splitting according to the QTBT,such as the CTU size, the minimum sizes for the quadtree and binary treeleaf nodes, the maximum size for the binary tree root node, and themaximum depth for the binary trees.

By way of a non-limiting example, FIG. 2 shows a CTU 100 partitionedinto CUs 102, with solid lines indicating quadtree splitting and dashedlines indicating binary tree splitting. As illustrated, the binarysplitting allows horizontal splitting and vertical splitting to definethe structure of the CTU and its subdivision into CUs.

FIG. 3 shows a QTBT representation of FIG. 2's partitioning. A quadtreeroot node represents the CTU 100, with each child node in the quadtreeportion representing one of four square blocks split from a parentsquare block. The square blocks represented by the quadtree leaf nodescan then be divided symmetrically zero or more times using binary trees,with the quadtree leaf nodes being root nodes of the binary trees,representing the parent coding unit that is partitioned into two childcoding units. At each level of the binary tree portion, a block can bedivided symmetrically, either vertically or horizontally. A flag set to“0” indicates that the block is symmetrically split horizontally, whilea flag set to “1” indicates that the block is symmetrically splitvertically.

After quadtree splitting and binary tree splitting, the blocksrepresented by the QTBT's leaf nodes represent the final CUs 102 to becoded, such as coding using inter prediction or intra prediction. Forslices or full frames coded with inter prediction, differentpartitioning structures can be used for luma and chroma components. Forexample, for an inter slice a CU 102 can have Coding Blocks (CBs) fordifferent color components, such as such as one luma CB and two chromaCBs. For slices or full frames coded with intra prediction, thepartitioning structure can be the same for luma and chroma components.

FIG. 4 depicts a simplified block diagram for CU coding in a WETencoder. The main stages of video coding include partitioning toidentify CUs 102 as described above, followed by encoding CUs 102 usingprediction at 404 or 406, generation of a residual CU 410 at 408,transformation at 412, quantization at 416, and entropy coding at 420.The encoder and encoding process illustrated in FIG. 4 also includes adecoding process that is described in more detail below.

Given a current CU 102, the encoder can obtain a prediction CU 402either spatially using intra prediction at 404 or temporally using interprediction at 406. The basic idea of prediction coding is to transmit adifferential, or residual, signal between the original signal and aprediction for the original signal. At the receiver side, the originalsignal can be reconstructed by adding the residual and the prediction,as will be described below. Because the differential signal has a lowercorrelation than the original signal, fewer bits are needed for itstransmission.

A sequence of coding units may make up a slice, and one or more slicesmay make up a picture. A slice may include one or more slice segments,each in its own NAL unit. A slice or slice segment may include headerinformation for the slice or bitstream.

A slice, such as an entire picture or a portion of a picture, codedentirely with intra-predicted CUs can be an I slice that can be decodedwithout reference to other slices, and as such can be a possible pointwhere decoding can begin. A slice coded with at least someinter-predicted CUs can be a predictive (P) or bi-predictive (B) slicethat can be decoded based on one or more reference pictures. P slicesmay use intra-prediction and inter-prediction with previously codedslices. For example, P slices may be compressed further than theI-slices by the use of inter-prediction, but need the coding of apreviously coded slice to code them. B slices can use data from previousand/or subsequent slices for its coding, using intra-prediction orinter-prediction using an interpolated prediction from two differentframes, thus increasing the accuracy of the motion estimation process.In some cases P slices and B slices can also or alternately be encodedusing intra block copy, in which data from other portions of the sameslice is used.

As will be discussed below, intra prediction or inter prediction aretechniques in intra coding that can be performed based on reconstructedCUs 434 from previously coded CUs 102, such as neighboring CUs 102 orCUs 102 in reference pictures.

When a CU 102 is coded spatially with intra prediction at 404, an intraprediction mode can be found that best predicts pixel values of the CU102 based on samples from neighboring CUs 102 in the picture.

When coding a CU's luma component, the encoder can generate a list ofcandidate intra prediction modes. While HEVC had 35 possible intraprediction modes for luma components, in NET there are 67 possible intraprediction modes for luma components. These include a planar mode thatuses a three dimensional plane of values generated from neighboringpixels, a DC mode that uses values averaged from neighboring pixels, andthe 65 directional modes shown in FIG. 5 that use values copied fromneighboring pixels along the indicated directions.

When generating a list of candidate intra prediction modes for a CU'sluma component, the number of candidate modes on the list can depend onthe CU's size. The candidate list can include: a subset of HEVC's 35modes with the lowest SATD (Sum of Absolute Transform Difference) costs;new directional modes added for NET that neighbor the candidates foundfrom the HEVC modes; and modes from a set of six most probable modes(MPMs) for the CU 102 that are identified based on intra predictionmodes used for previously coded neighboring blocks as well as a list ofdefault modes.

When coding a CU's chroma components, a list of candidate intraprediction modes can also be generated. The list of candidate modes caninclude modes generated with cross-component linear model projectionfrom luma samples, intra prediction modes found for luma CB s inparticular collocated positions in the chroma block, and chromaprediction modes previously found for neighboring blocks. The encodercan find the candidate modes on the lists with the lowest ratedistortion costs, and use those intra prediction modes when coding theCU's luma and chroma components. Syntax can be coded in the bitstreamthat indicates the intra prediction modes used to code each CU 102.

After the best intra prediction modes for a CU 102 have been selected,the encoder can generate a prediction CU 402 using those modes. When theselected modes are directional modes, a 4-tap filter can be used toimprove the directional accuracy. Columns or rows at the top or leftside of the prediction block can be adjusted with boundary predictionfilters, such as 2-tap or 3-tap filters.

The prediction CU 402 can be smoothed further with a position dependentintra prediction combination (PDPC) process that adjusts a prediction CU402 generated based on filtered samples of neighboring blocks usingunfiltered samples of neighboring blocks, or adaptive reference samplesmoothing using 3-tap or 5-tap low pass filters to process referencesamples.

In some embodiments, syntax can be coded in the bitstream that indicatesthe intra prediction modes used to code each CU 102. However, asdescribed below with respect to FIGS. 7-17, in other embodiments theencoder can save overhead in the bitstream by omitting information thatindicates the intra prediction mode used to encode a CU 102, and adecoder can use template matching to generate a prediction block whendecoding a CU 102 encoded with intra prediction.

When a CU 102 is coded temporally with inter prediction at 406, a set ofmotion vectors (MVs) can be found that points to samples in referencepictures that best predict pixel values of the CU 102. Inter predictionexploits temporal redundancy between slices by representing adisplacement of a block of pixels in a slice. The displacement isdetermined according to the value of pixels in previous or followingslices through a process called motion compensation. Motion vectors andassociated reference indices that indicate pixel displacement relativeto a particular reference picture can be provided in the bitstream to adecoder, along with the residual between the original pixels and themotion compensated pixels. The decoder can use the residual and signaledmotion vectors and reference indices to reconstruct a block of pixels ina reconstructed slice.

In JVET, motion vector accuracy can be stored at 1/16 pel, and thedifference between a motion vector and a CU's predicted motion vectorcan be coded with either quarter-pel resolution or integer-pelresolution.

In JVET motion vectors can be found for multiple sub-CUs within a CU102, using techniques such as advanced temporal motion vector prediction(ATMVP), spatial-temporal motion vector prediction (STMVP), affinemotion compensation prediction, pattern matched motion vector derivation(PMMVD), and/or bi-directional optical flow (BIO).

Using ATMVP, the encoder can find a temporal vector for the CU 102 thatpoints to a corresponding block in a reference picture. The temporalvector can be found based on motion vectors and reference pictures foundfor previously coded neighboring CUs 102. Using the reference blockpointed to by a temporal vector for the entire CU 102, a motion vectorcan be found for each sub-CU within the CU 102.

STMVP can find motion vectors for sub-CUs by scaling and averagingmotion vectors found for neighboring blocks previously coded with interprediction, together with a temporal vector.

Affine motion compensation prediction can be used to predict a field ofmotion vectors for each sub-CU in a block, based on two control motionvectors found for the top corners of the block. For example, motionvectors for sub-CUs can be derived based on top corner motion vectorsfound for each 4×4 block within the CU 102.

PMMVD can find an initial motion vector for the current CU 102 usingbilateral matching or template matching. Bilateral matching can look atthe current CU 102 and reference blocks in two different referencepictures along a motion trajectory, while template matching can look atcorresponding blocks in the current CU 102 and a reference pictureidentified by a template. The initial motion vector found for the CU 102can then be refined individually for each sub-CU.

BIO can be used when inter prediction is performed with bi-predictionbased on earlier and later reference pictures, and allows motion vectorsto be found for sub-CUs based on the gradient of the difference betweenthe two reference pictures.

In some situations local illumination compensation (LIC) can be used atthe CU level to find values for a scaling factor parameter and an offsetparameter, based on samples neighboring the current CU 102 andcorresponding samples neighboring a reference block identified by acandidate motion vector. In JVET, the LIC parameters can change and besignaled at the CU level.

For some of the above methods the motion vectors found for each of aCU's sub-CUs can be signaled to decoders at the CU level. For othermethods, such as PMMVD and BIO, motion information is not signaled inthe bitstream to save overhead, and decoders can derive the motionvectors through the same processes.

After the motion vectors for a CU 102 have been found, the encoder cangenerate a prediction CU 402 using those motion vectors. In some cases,when motion vectors have been found for individual sub-CUs, OverlappedBlock Motion Compensation (OBMC) can be used when generating aprediction CU 402 by combining those motion vectors with motion vectorspreviously found for one or more neighboring sub-CUs.

When bi-prediction is used, JVET can use decoder-side motion vectorrefinement (DMVR) to find motion vectors. DMVR allows a motion vector tobe found based on two motion vectors found for bi-prediction using abilateral template matching process. In DMVR, a weighted combination ofprediction CUs 402 generated with each of the two motion vectors can befound, and the two motion vectors can be refined by replacing them withnew motion vectors that best point to the combined prediction CU 402.The two refined motion vectors can be used to generate the finalprediction CU 402.

At 408, once a prediction CU 402 has been found with intra prediction at404 or inter prediction at 406 as described above, the encoder cansubtract the prediction CU 402 from the current CU 102 find a residualCU 410.

The encoder can use one or more transform operations at 412 to convertthe residual CU 410 into transform coefficients 414 that express theresidual CU 410 in a transform domain, such as using a discrete cosineblock transform (DCT-transform) to convert data into the transformdomain. JVET allows more types of transform operations than HEVC,including DCT-II, DST-VII, DST-VII, DCT-VIII, DST-I, and DCT-Voperations. The allowed transform operations can be grouped intosub-sets, and an indication of which sub-sets and which specificoperations in those sub-sets were used can be signaled by the encoder.In some cases, large block-size transforms can be used to zero out highfrequency transform coefficients in CUs 102 larger than a certain size,such that only lower-frequency transform coefficients are maintained forthose CUs 102.

In some cases a mode dependent non-separable secondary transform(MDNSST) can be applied to low frequency transform coefficients 414after a forward core transform. The MDNSST operation can use aHypercube-Givens Transform (HyGT) based on rotation data. When used, anindex value identifying a particular MDNSST operation can be signaled bythe encoder.

At 416, the encoder can quantize the transform coefficients 414 intoquantized transform coefficients 416. The quantization of eachcoefficient may be computed by dividing a value of the coefficient by aquantization step, which is derived from a quantization parameter (QP).In some embodiments, the Qstep is defined as 2^((QP-4)/6). Because highprecision transform coefficients 414 can be converted into quantizedtransform coefficients 416 with a finite number of possible values,quantization can assist with data compression. Thus, quantization of thetransform coefficients may limit an amount of bits generated and sent bythe transformation process. However, while quantization is a lossyoperation, and the loss by quantization cannot be recovered, thequantization process presents a trade-off between quality of thereconstructed sequence and an amount of information needed to representthe sequence. For example, a lower QP value can result in better qualitydecoded video, although a higher amount of data may be required forrepresentation and transmission. In contrast, a high QP value can resultin lower quality reconstructed video sequences but with lower data andbandwidth needs.

NET can utilize variance-based adaptive quantization techniques, whichallows every CU 102 to use a different quantization parameter for itscoding process (instead of using the same frame QP in the coding ofevery CU 102 of the frame). The variance-based adaptive quantizationtechniques adaptively lowers the quantization parameter of certainblocks while increasing it in others. To select a specific QP for a CU102, the CU's variance is computed. In brief, if a CU's variance ishigher than the average variance of the frame, a higher QP than theframe's QP may be set for the CU 102. If the CU 102 presents a lowervariance than the average variance of the frame, a lower QP may beassigned.

At 420, the encoder can find final compression bits 422 by entropycoding the quantized transform coefficients 418. Entropy coding aims toremove statistical redundancies of the information to be transmitted. InNET, CABAC (Context Adaptive Binary Arithmetic Coding) can be used tocode the quantized transform coefficients 418, which uses probabilitymeasures to remove the statistical redundancies. For CUs 102 withnon-zero quantized transform coefficients 418, the quantized transformcoefficients 418 can be converted into binary. Each bit (“bin”) of thebinary representation can then be encoded using a context model. A CU102 can be broken up into three regions, each with its own set ofcontext models to use for pixels within that region.

Multiple scan passes can be performed to encode the bins. During passesto encode the first three bins (bin0, bin 1, and bin2), an index valuethat indicates which context model to use for the bin can be found byfinding the sum of that bin position in up to five previously codedneighboring quantized transform coefficients 418 identified by atemplate.

A context model can be based on probabilities of a bin's value being ‘0’or ‘1’. As values are coded, the probabilities in the context model canbe updated based on the actual number of ‘0’ and ‘1’ values encountered.While HEVC used fixed tables to re-initialize context models for eachnew picture, in NET the probabilities of context models for newinter-predicted pictures can be initialized based on context modelsdeveloped for previously coded inter-predicted pictures.

The encoder can produce a bitstream that contains entropy encoded bits422 of residual CUs 410, prediction information such as selected intraprediction modes or motion vectors, indicators of how the CUs 102 werepartitioned from a CTU 100 according to the QTBT structure, and/or otherinformation about the encoded video. The bitstream can be decoded by adecoder as discussed below. As described below with respect to FIGS.7-17, in some embodiments the encoder can save overhead in the bitstreamby omitting information from the bitstream that indicates which intraprediction modes were used to encode CUs 102, and the decoder can usetemplate matching when decoding CUs 102 encoded with intra prediction.

In addition to using the quantized transform coefficients 418 to findthe final compression bits 422, the encoder can also use the quantizedtransform coefficients 418 to generate reconstructed CUs 434 byfollowing the same decoding process that a decoder would use to generatereconstructed CUs 434. Thus, once the transformation coefficients havebeen computed and quantized by the encoder, the quantized transformcoefficients 418 may be transmitted to the decoding loop in the encoder.After quantization of a CU's transform coefficients, a decoding loopallows the encoder to generate a reconstructed CU 434 identical to theone the decoder generates in the decoding process. Accordingly, theencoder can use the same reconstructed CUs 434 that a decoder would usefor neighboring CUs 102 or reference pictures when performing intraprediction or inter prediction for a new CU 102. Reconstructed CUs 102,reconstructed slices, or full reconstructed frames may serve asreferences for further prediction stages.

At the encoder's decoding loop (and see below, for the same operationsin the decoder) to obtain pixel values for the reconstructed image, adequantization process may be performed. To dequantize a frame, forexample, a quantized value for each pixel of a frame is multiplied bythe quantization step, e.g., (Qstep) described above, to obtainreconstructed dequantized transform coefficients 426. For example, inthe decoding process shown in FIG. 4 in the encoder, the quantizedtransform coefficients 418 of a residual CU 410 can be dequantized at424 to find dequantized transform coefficients 426. If an MDNSSToperation was performed during encoding, that operation can be reversedafter dequantization.

At 428, the dequantized transform coefficients 426 can be inversetransformed to find a reconstructed residual CU 430, such as by applyinga DCT to the values to obtain the reconstructed image. At 432 thereconstructed residual CU 430 can be added to a corresponding predictionCU 402 found with intra prediction at 404 or inter prediction at 406, inorder to find a reconstructed CU 434. While in some embodiments theencoder can perform intra prediction at 404 as described above, in otherembodiments the encoder can follow the process described below withrespect to FIGS. 7-17 for intra prediction template matching to generatea prediction CU 402 in the same way that a decoder would use templatematching for intra prediction if information identifying the intraprediction mode used for the CU 102 is omitted from the bitstream.

At 436, one or more filters can be applied to the reconstructed dataduring the decoding process (in the encoder or, as described below, inthe decoder), at either a picture level or CU level. For example, theencoder can apply a deblocking filter, a sample adaptive offset (SAO)filter, and/or an adaptive loop filter (ALF). The encoder's decodingprocess may implement filters to estimate and transmit to a decoder theoptimal filter parameters that can address potential artifacts in thereconstructed image. Such improvements increase the objective andsubjective quality of the reconstructed video. In deblocking filtering,pixels near a sub-CU boundary may be modified, whereas in SAO, pixels ina CTU 100 may be modified using either an edge offset or band offsetclassification. JVET's ALF can use filters with circularly symmetricshapes for each 2×2 block. An indication of the size and identity of thefilter used for each 2×2 block can be signaled.

If reconstructed pictures are reference pictures, they can be stored ina reference buffer 438 for inter prediction of future CUs 102 at 406.

During the above steps, JVET allows a content adaptive clippingoperations to be used to adjust color values to fit between lower andupper clipping bounds. The clipping bounds can change for each slice,and parameters identifying the bounds can be signaled in the bitstream.

FIG. 6 depicts a simplified block diagram for CU coding in a JVETdecoder. A JVET decoder can receive a bitstream containing informationabout encoded CUs 102. The bitstream can indicate how CUs 102 of apicture were partitioned from a CTU 100 according to a QTBT structure.By way of a non-limiting example, the bitstream can identify how CUs 102were partitioned from each CTU 100 in a QTBT using quadtreepartitioning, symmetric binary partitioning, and/or asymmetric binarypartitioning. The bitstream can also indicate prediction information forthe CUs 102 such as intra prediction modes or motion vectors, and bits602 representing entropy encoded residual CUs. In some embodiments theencoder can have omitted information in the bitstream about intraprediction modes used to encode some or all CUs 102 coded using intraprediction, and as such the decoder can use template matching for intraprediction as described below with respect to FIGS. 7-17.

At 604 the decoder can decode the entropy encoded bits 602 using theCABAC context models signaled in the bitstream by the encoder. Thedecoder can use parameters signaled by the encoder to update the contextmodels' probabilities in the same way they were updated during encoding.

After reversing the entropy encoding at 604 to find quantized transformcoefficients 606, the decoder can dequantize them at 608 to finddequantized transform coefficients 610. If an MDNSST operation wasperformed during encoding, that operation can be reversed by the decoderafter dequantization.

At 612, the dequantized transform coefficients 610 can be inversetransformed to find a reconstructed residual CU 614. At 616, thereconstructed residual CU 614 can be added to a corresponding predictionCU 626 found with intra prediction at 622 or inter prediction at 624, inorder to find a reconstructed CU 618. As described below with respect toFIGS. 7-17, in some embodiments the decoder can find the prediction CU626 using template matching for intra prediction.

At 620, one or more filters can be applied to the reconstructed data, ateither a picture level or CU level. For example, the decoder can apply adeblocking filter, a sample adaptive offset (SAO) filter, and/or anadaptive loop filter (ALF). As described above, the in-loop filterslocated in the decoding loop of the encoder may be used to estimateoptimal filter parameters to increase the objective and subjectivequality of a frame. These parameters are transmitted to the decoder tofilter the reconstructed frame at 620 to match the filteredreconstructed frame in the encoder.

After reconstructed pictures have been generated by findingreconstructed CUs 618 and applying signaled filters, the decoder canoutput the reconstructed pictures as output video 628. If reconstructedpictures are to be used as reference pictures, they can be stored in areference buffer 630 for inter prediction of future CUs 102 at 624.

While in some embodiments the bitstream received by a JVET decoder caninclude syntax identifying which intra prediction mode was used toencode a CU 102 with intra prediction, such that the decoder candirectly use the signaled intra prediction mode at 622 to generate aprediction CU 626, in other embodiments such syntax can be omitted tosave overhead by reducing the number of bits in the bitstream. In theseembodiments, when the decoder is not provided with an indication ofwhich intra prediction mode was used to encode a CU 102, the decoder canuse template matching for intra prediction at 622 to derive the intraprediction mode it should use to generate a prediction CU 626. In someembodiments an encoder can similarly use template matching for intraprediction at 404 when generating a prediction CU 402 to combine with areconstructed residual CU 430 at 432 within its decoding loop.

Predictors may be generated in intra coding to exploit correlationbetween the coding block and its neighbors. As described above, intraprediction is a type of intra coding for video compression that utilizesspatial neighbors of a pixel to create a predictor, from which aprediction residual between the pixel and its predictor may bedetermined. A video encoder may compress the residual predicted from thepredictor, resulting in the coding bitstream.

FIG. 7A depicts a method of intra prediction that relies on a singlereference line/tier. For angular prediction using a single referenceline, each pixel in the coding block is projected to the nearestreference line along the angular direction. The reference line may be areference row adjacent to the top boundary of the coding block or areference column adjacent to the left boundary of the coding block. Incertain embodiments, either the reference row or reference column isused in the predictor generation process, but not both. In certainembodiments, some angular modes do generate a predictor of a codingblock using both a top and left neighbor, but using only one sideneighbor in a predictor generation process of a pixel. Thus in anexample with HEVC's 35 nodes projected neighbors along reference columnmay serve as reference line for each of horizontal modes (modes 2-17)and projected neighbors along reference row may serve as the referenceline for each of vertical modes (modes 19-34).

By way of a non-limiting example, FIG. 7B depicts a prediction CU 726being generated from pixels in reference line 730. Since pixels with ashorter distance will often have a stronger correlation in a picture,the use of only the nearest reference line to predict a current block isreasonably employed in HEVC. For each intra prediction mode, a projectedneighbor position along the single reference line for each pixel withina coding unit may be determined using the angular direction associatedwith intra mode, and in one or more embodiments only one reference lineadjacent to a current coding block is used to predict samples inside theblock. Thus, in HEVC, for example, which allows 35 possible intraprediction modes, each intra prediction unit (PU) selects one intraprediction mode to be used, and the projected neighbors along referencecolumn may serve as the reference line for horizontal modes (modes 2-17)and projected neighbors along reference row may serve as the referenceline for vertical modes (modes 19-34).

Angular prediction is a copying-based process which assumes visualcontent follows a pure direction of propagation. As shown in FIG. 7C,all prediction modes in such scenario utilizes a same basic set ofreference samples from above and to the left of the image block to bepredicted. In FIG. 7C, reference samples are denoted Rx,y with (x,y)having its origin one pixel above and to the left of the block's topleft corner, and Px,y denotes a predicted sample value at position(x,y). Thus, each of reference samples Rx,y is used in prediction toobtain predicted samples Px,y for a block of size N×N samples.

However, as recognized herein, relying on only the nearest referenceline does not always generate the best predictor. For example, angularprediction using a prediction generation process that relies on only oneside of the neighbors may suffer from blocking artifacts. If noise isintroduced during video coding, for example, the nearest reference linemay be corrupted by noise, such noise propagating into the prediction.Relying on only one side of the neighbors may cause strong discontinuitybetween a boundary pixel and a neighbor pixel of the side that is notused in the prediction generation process. In some cases, theneighboring reference samples may be unavailable for intra prediction,such as at picture or slice boundaries, and thus replacement referencesamples are generated by repetition from closest available samples.Further, relying on a single reference line based method may also resultin incoherence caused by signal noise or the texture of the otherobject, and the nearest reference line may have a worse reconstructionquality in block-based video coding (e.g., in many block-based videocoding frameworks, pixels in different positions of a block havedifferent reconstruction quality).

In HEVC implementations, each intra prediction mode for generating aprediction pixel may have a unique prediction generation method based oneither a left-side neighbor (reference column) or top-size neighbor(reference row). Thus, referring to FIGS. 7A and 7B, of each intraprediction mode has a unique prediction generation method based oneither a left-side neighbor or top-size neighbor from either a referencerow or reference column in Reference Tier 0. Each intra prediction modeused for each intra prediction unit must be signaled as overhead in thecoding bitstream.

Disclosed herein are techniques for increasing the number of possiblereference tiers available for intra prediction. Also disclosed is theuse of both side neighbors to generate a predicting pixel. In otherwords, besides the nearest reference line, further reference lines maybe utilized for intra prediction of a coding unit. And both sideneighbors, two neighbors on a reference row and/or reference column, maybe use from a single or multiple reference lines.

By increasing the number of possible reference tiers available for intraprediction, from one reference to N reference tiers (N is larger than1), the disclosed techniques may improve encoder speed and/orefficiency. For example, the diversity employed in the predictionprocess by forming predictor block based on one of many possiblereference lines, instead of just the adjacent reference line, mayimprove the predictive power of intra prediction process, such as wherea reference line with less noise is used,

Thus, in one or more embodiments where one or more reference tiers areavailable, the intra sample prediction process may be performed byextrapolating sample values from reconstructed reference samples, wheresample locations within one coding block are projected onto one or morereference lines depending on the directionality of the selectedprediction mode.

In one or more embodiments, the intra direction mode determines whichreference line, e.g., within which tier, is selected to generate intrapredictors. Instead of using reconstructed samples from a correspondingneighboring block, an index coded in the bitstream may signal to thedecoder to indicate which reference tier is chosen for an intradirectional mode.

In one or more embodiments, a best reference line or lines can be chosenfrom a plurality of reference lines according to a sum of absolutetransformed differences between the predict block and the originalblock, where each reference line will check all of the angulardirections.

In contrast to HEVC, the number of directional modes increases for JVET.As illustrated in FIG. 5, the JVET compression tools for intraprediction include 67 intra prediction modes (planar, DC, and 65 intra,or angular, directional modes), adding 32 additional angular modes toimprove coding performance. Thus, not only are there an increase in thenumber of mode directions, disclosed are techniques for combining anincreased number of nodes with an increased number of reference lines.

FIG. 8 depicts an example of multiple line-based intra prediction forJVET intra prediction modes, where intra prediction may generatepredictors from multiple reference tiers for intra directional modes,such as generating a predictor based on neighbors from both thereference row adjacent to the top and the reference column adjacent tothe side, or from reference rows and/or columns in reference tiers thatare not adjacent to the coding unit.

A predicted sample P[x,y] may be obtained by projecting its location toa selected reference row of pixels by applying a selected predictiondirection and interpolating a value for the sample. Interpolation may beperformed linearly using the two closest reference samples from theselected reference line.

As described in more detail below, the techniques disclosed herein maybe extended to multiple reference lines to support multiple line-basedintra prediction by properly adjusting a distance between the predictorposition and projected position. A reference line may include at leastone of a reference row, a reference column, or a combination of areference row and reference column. To make the combination approachmore flexible, more than one reference line indicator can be used. Forexample, where two reference lines are used, one reference line mayindicate the main reference line and a second reference line mayindicate the side reference line. A reference column or row that ispartially used in predictor generation may be called a side referenceline.

In one or more embodiments, predictor pixels for angular prediction aregenerated using pixels at projected position on both a top reference rowand left reference column. Predictor generation can be done in threesteps. First, a coding system may project a pixel position along a mainreference line according to an angular direction definition of thecoding intra prediction mode. The pixel value(s) of the projectedposition may be computed using linear interpolation between twoneighboring reconstructed pixels. Second, the coding system may projectpixel position(s) along the side reference line according to the angulardefinition of the same coding mode. The pixel value(s) of the projectedposition may be computed using linear interpolation between twoneighboring reconstructed pixels. Third, the projected pixel value(s) onthe main reference line may be combined with the projected pixelvalue(s) on the side reference. One example for combination, as shown inEquation (1), is to weight the values according to distance between thepredictor pixels and projected pixel positions on the main and sidereferences.

P[x,y]=(((w1*MainRecon[x′,y′])+(w2*SideRecon[x″,y″])+(w1+w2)/2)/(w1+w2))  (1)

Where:

-   -   w(n) is a weighting between two reference samples corresponding        to a projected subpixel location between R_(i,0) and R_(i+1,0)        Reference sample index I and weighted parameter w are calculated        based on a projection displacement associated with a selected        prediction direction.    -   MainRecon[x′,y′] is a pixel value of neighbor at projected        position (x′,y′), corresponding to the predicting pixel (x,y),        along the main reference.    -   SideRecon[x′,y′] is a pixel value of neighbor at projected        position (x″,y″), corresponding to the predicting pixel (x,y),        along the side reference.

For each angular mode, a corresponding weighted angular mode may be usedwhich applies a weight to the predicted samples on the reference row andreference column when computing the predictor pixel P[x,y] at coordinatex,y. Two different weighted values may apply, and S[n] illustrates anarray of weight parameters. Thus, in one or more embodiments, theweighted prediction method is used for the predictor pixel in the codingblock instead of the regular, non-weighted calculation for the predictorpixel, and the weighted prediction method may be used for one or more ofthe intra prediction angular modes.

As described herein, JVET introduces additional intra prediction modesthat expand upon the 33 modes in HEVC. Consider an example in whichthere are 67 total modes, 65 of which are angular modes, as shown inFIG. 5. Thus, where 0 is the planar mode,1 is the DC planar mode, assumethe 65 angular modes are modes 2-66 (i.e., 65 angular modes). A specificexample of the disclosed techniques is now described using JVET mode 2and mode 66, but it should be understood that the ideas disclosed forweighted angular prediction may cover one or more of the JVET angularmodes. Further it should be understood that there may be more than 67intra prediction modes.

For the JVET mode 2 or mode 66 example, predictor pixel at coordinate(x,y), P[x,y], is calculated as described in Equation (2), with theweights assigned as shown:

P[x,y]=((((x+1)*Recon[x+y+2,−1])+((y+1)*(Recon[−1,x+y+2]))+(y+x+2)/2)/(y+x+2))  (2)

Where:

-   -   Recon[0,0] is a reconstructed pixel at top left coordinate (0,0)        of the current PU.

An exception to weighted angular prediction may occur when a projectedreference position on the side reference refers to a reconstructedposition that is not available. There are several ways to handle theexception; e.g., use value of last available reconstructed pixel ordefault value for that projected position, or disable weighted angularprediction and use projected pixel position on the main reference only.

Equation (2) above involves division operations, which can be costly interms of complexity. As proposed below in equation (3), the divisionoperations can be roughly converted into scale operations to make themimplementation friendly, thus introducing the disclosed weighted angularprediction implementation.

P[x,y]=((((x+1)*Recon[x+y+2,−1])+((y+1)*Recon[−1,x+y+2])*S[y+x+2]+(y+x+2)/2)>>ShiftDenom)  (3)

Where:

S[n] is a weight of parameter n, and

>>denotes a bit shift operation to the right

ShiftDenom is a factor for shifted down operation. In embodiments, S[n]may be the same weighting table used in UW-Planar implementations.

Specifically, S[n] may be an approximation of a factor

$\begin{matrix}{{S\lbrack n\rbrack} = {{Round}\left( \frac{\left( {1{\operatorname{<<}{Shift}}\mspace{14mu} {Denom}} \right)}{n} \right)}} & (4)\end{matrix}$

and can be described as shown in equation (4).

$\frac{1}{n},$

FIG. 9 is an example of S[n], where sum of width and height is 256 andShiftDenom=10.

FIG. 10 illustrates another example of S[n], where the sum of the widthand height is 512 and ShiftDenom=10.

The use of additional reference lines that are further from the codingunit than the reference line that is adjacent may increase prediction.As shown in FIG. 8, the intra directional mode for the coding unit couldchoose one or more of N reference tiers to generate the predictors. Asdescribed in more detail below, the predictor p[x,y] may be generatedfrom one of a plurality of reference samples within each reference line.

Overhead bit(s) may signal in the bitstream which reference line is tobe used for intra predictor generation. For example, a syntax element,such as a flag, may signal which reference tier is chosen for an intradirectional mode. Overhead bit(s) may also signal in the bitstream whichreference line is to be used for intra predictor generation. In one ormore embodiments, two overhead bits may be used, one to indicate areference line index for the main reference, and another to indicate theside reference line.

Under some circumstances, the shift conversion used in Equation (3) doesnot provide accurate outputs resulting in poor coding efficiency. Theineffectiveness is due to a conversion process which allows error toaccumulate linearly with distance. In one or more embodiments, the erroris reduced by exploiting the fact that weight for horizontal andvertical predictors are complimentary in (3) and hence the real weightcan be computed based on that of horizontal or vertical predictor,whichever is more accurate. An example of this approach is nowdescribed.

In an example of the disclosed techniques, parameters horWeight andverWeight are introduced and (3) can now be described as (5).

$\begin{matrix}{{{P\left\lbrack {x,y} \right\rbrack} = \left( {\left( {\left( {{horWeight}*{{Recon}\left\lbrack {{x + y + 2},{- 1}} \right\rbrack}} \right) + {{verWeight}*{{Recon}\left\lbrack {{- 1},{x + y + 2}} \right\rbrack}}} \right) + {\left( {y + x + 2} \right)/2}} \right)}\operatorname{>>}} & (5) \\{{horWeight} = \left\{ \begin{matrix}{\left( {1{\operatorname{<<}{Shift}}\mspace{14mu} {Denom}} \right) - {{verWeigh}t}} & {{{when}\mspace{14mu} x} < y} \\{\left( {y + 1} \right)*{S\left\lbrack {x + y + 2} \right\rbrack}} & {otherwise}\end{matrix} \right.} & (6) \\{{verWeight} = \left\{ \begin{matrix}{\left( {x + 1} \right)*{S\left\lbrack {x + y + 2} \right\rbrack}} & {{{when}\mspace{14mu} x} < y} \\{\left( {1{\operatorname{<<}{Shift}}\mspace{14mu} {Denom}} \right) - {horWeight}} & {otherwise}\end{matrix} \right.} & (7)\end{matrix}$

In one or more embodiments for a weighted angular prediction, theresulting weighted angular prediction mode may or may not replace theoriginal angular mode. As an example, new weighted angular mode 2, or 66may replace original mode 2, or 66. In one or more embodiments, bothweighted angular mode and original angular mode are retained. Disclosedherein are techniques for coding added weighted angular modes. Thus, inone or more embodiments, one or more non-weighted angular modes has acorresponding weighted angular mode, and both the non-weighted andweighted modes are available.

As disclosed herein, both weighted angular mode and original angularmode for intra code are retained. In JVET, there are 65 angular modes.Thus, for each angular mode, except horizontal and vertical modes, theremay be a corresponding weighted angular mode for intra code.

Assume for purposes of example, that JVET only adds one additional mode,which is a weighted mode corresponding to just one JVET non-weightedangular mode. Thus, in the example where JVET has 67 non-weightedintra-prediction modes, 65 of them angular, the added weighted angularmode increases the number of modes available to 68 modes. It is notedthat each non-weighted angular mode may have a corresponding weightedmode.

In one or more embodiments, a coded syntax may indicate which intraprediction mode should be used when generating the predictor for apredicted pixel. As described above, a weighted JVET angular mode may beproduced for each non-weighted, regular JVET angular mode. Thus, duringcoding, the encoder or decoder may need to make a decision regardingwhether to use the non-weighted or weighted angular mode to generate apredictor. Where both a non-weighted and weighted angular mode areavailable for coding, that means additional processing to determinewhich mode to use to generate a predictor.

In one or more embodiments, a syntax element is coded to indicatewhether a weighted or non-weighted mode is used in the prediction, thesyntax indicating whether or not a weighted version of an angular modeexists or is available and whether it is used for prediction. In anexample embodiment, in order to code each of the additional weightedangular modes, a flag may signal a distinction between original angularmode and its corresponding weighted angular mode. Such flag may assiston angular mode selection during intra coding. In embodiments, the flag,e.g., a weighted_angular_mode flag, may be used to distinguish originalangular mode or its corresponding weighted angular mode. A possiblesyntax arrangement is proposed as follows.

decode intra_mode with current JVET method if (intra_mode== DC/Planar)generation_DC/Planar_prediction  else decode weighted_angular_modeif(weighted_angular_mode) generate weighted_angular _prediction  else generate original angular _prediction

Thus, the coded syntax may indicate whether to use a weighted ornon-weighted angular mode without a distinction or a need to codewhether a weighted mode is even available. For example, assume only 3modes have a corresponding weighted mode. For any other modes used inprediction, the syntax will indicate that the non-weighted mode is to beused for prediction (because a non-weighted corresponding mode isunavailable). Thus, coding the bitstream may not need further processingto indicate whether a weighted mode is available, the coding simplyoperates according to the flag, and may be agnostic to whichcorresponding weighted modes are available for which modes. Thus, in oneor more embodiments where both a non-weighted and a weighted angularmode are available, the coding process may choose between non-weightedand weighted for a single mode.

With the above syntax, most probable mode (MPM) coding may remainunchanged. But, in one or more embodiments, the additional flag bin,weighted_angular_mode, may be required. The weighted_angular_mode flagmay be a one bit flag that identifies whether a correspondingweighted_angular_mode exists (e.g., 1=True (weighted_angular_modepresent, 0=False (weighted_angular_mode not present). In one or moreembodiments, the value of the weighted_angular_mode flag may identify aparticular angular mode, which may be implemented with multiple bits.

Practically, it may not be necessary to have the correspondingweighted_angular_mode for each angular mode due to the codingperformance and complexity. Thus, in one or more embodiments, only alimited number of original angular modes have a corresponding weightedangular modes as a new intra modes. For example, the original angularmode 66 may be the only angular mode allowed to have itsweighted_angular_mode. In such example, the result is DC, Planar, 65original angular modes, plus one weighted_angular_mode, which includesthe original angular modes 66 (for a total of 68 modes for luma block).The weighted_angular_mode may be treated as mode 67. It should beunderstood that if more original angular modes are allowed to have acorresponding weighted_angular_mode, the result will be to haveadditional modes.

There are at least two ways to code the weighted angular modes (such asmode 67 in the example above). For example, in one or more embodiments,mode 67 may be treated as a regular mode and is included in the MPM listas one of default modes. In one or more embodiments, mode 67 is notincluded as one of default modes for MPM unless or until it is used byone of the neighboring blocks.

The execution of the sequences of instructions required to practice theembodiments can be performed by a computer system 1100 as shown in FIG.11. In an embodiment, execution of the sequences of instructions isperformed by a single computer system 1100. According to otherembodiments, two or more computer systems 1100 coupled by acommunication link 1115 can perform the sequence of instructions incoordination with one another. Although a description of only onecomputer system 1100 will be presented below, however, it should beunderstood that any number of computer systems 1100 can be employed topractice the embodiments.

A computer system 1100 according to an embodiment will now be describedwith reference to FIG. 11, which is a block diagram of the functionalcomponents of a computer system 1100. As used herein, the term computersystem 1100 is broadly used to describe any computing device that canstore and independently run one or more programs.

Each computer system 1100 can include a communication interface 1114coupled to the bus 1106. The communication interface 1114 providestwo-way communication between computer systems 1100. The communicationinterface 1114 of a respective computer system 1100 transmits andreceives electrical, electromagnetic or optical signals, which includedata streams representing various types of signal information, e.g.,instructions, messages and data. A communication link 1115 links onecomputer system 1100 with another computer system 1100. For example, thecommunication link 1115 can be a LAN, in which case the communicationinterface 1114 can be a LAN card, or the communication link 1115 can bea PSTN, in which case the communication interface 1114 can be anintegrated services digital network (ISDN) card or a modem, or thecommunication link 1115 can be the Internet, in which case thecommunication interface 1114 can be a dial-up, cable or wireless modem.

A computer system 1100 can transmit and receive messages, data, andinstructions, including program, i.e., application, code, through itsrespective communication link 1115 and communication interface 1114.Received program code can be executed by the respective processor(s)1107 as it is received, and/or stored in the storage device 1110, orother associated non-volatile media, for later execution.

In an embodiment, the computer system 1100 operates in conjunction witha data storage system 1131, e.g., a data storage system 1131 thatcontains a database 1132 that is readily accessible by the computersystem 1100. The computer system 1100 communicates with the data storagesystem 1131 through a data interface 1133. A data interface 1133, whichis coupled to the bus 1106, transmits and receives electrical,electromagnetic or optical signals, which include data streamsrepresenting various types of signal information, e.g., instructions,messages and data. In embodiments, the functions of the data interface1133 can be performed by the communication interface 1114.

Computer system 1100 includes a bus 1106 or other communicationmechanism for communicating instructions, messages and data,collectively, information, and one or more processors 1107 coupled withthe bus 1106 for processing information. Computer system 1100 alsoincludes a main memory 1108, such as a random access memory (RAM) orother dynamic storage device, coupled to the bus 1106 for storingdynamic data and instructions to be executed by the processor(s) 1107.The main memory 1108 also can be used for storing temporary data, i.e.,variables, or other intermediate information during execution ofinstructions by the processor(s) 1107.

The computer system 1100 can further include a read only memory (ROM)1109 or other static storage device coupled to the bus 1106 for storingstatic data and instructions for the processor(s) 1107. A storage device1110, such as a magnetic disk or optical disk, can also be provided andcoupled to the bus 1106 for storing data and instructions for theprocessor(s) 1107.

A computer system 1100 can be coupled via the bus 1106 to a displaydevice 1111, such as, but not limited to, a cathode ray tube (CRT) or aliquid-crystal display (LCD) monitor, for displaying information to auser. An input device 1112, e.g., alphanumeric and other keys, iscoupled to the bus 1106 for communicating information and commandselections to the processor(s) 1107.

According to one embodiment, an individual computer system 1100 performsspecific operations by their respective processor(s) 1107 executing oneor more sequences of one or more instructions contained in the mainmemory 1108. Such instructions can be read into the main memory 1108from another computer-usable medium, such as the ROM 1109 or the storagedevice 1110. Execution of the sequences of instructions contained in themain memory 1108 causes the processor(s) 1107 to perform the processesdescribed herein. In alternative embodiments, hard-wired circuitry canbe used in place of or in combination with software instructions. Thus,embodiments are not limited to any specific combination of hardwarecircuitry and/or software.

The term “computer-usable medium,” as used herein, refers to any mediumthat provides information or is usable by the processor(s) 1107. Such amedium can take many forms, including, but not limited to, non-volatile,volatile and transmission media. Non-volatile media, i.e., media thatcan retain information in the absence of power, includes the ROM 1109,CD ROM, magnetic tape, and magnetic discs. Volatile media, i.e., mediathat cannot retain information in the absence of power, includes themain memory 1108. Transmission media includes coaxial cables, copperwire and fiber optics, including the wires that comprise the bus 1106.Transmission media can also take the form of carrier waves; i.e.,electromagnetic waves that can be modulated, as in frequency, amplitudeor phase, to transmit information signals. Additionally, transmissionmedia can take the form of acoustic or light waves, such as thosegenerated during radio wave and infrared data communications. In theforegoing specification, the embodiments have been described withreference to specific elements thereof. It will, however, be evidentthat various modifications and changes can be made thereto withoutdeparting from the broader spirit and scope of the embodiments. Forexample, the reader is to understand that the specific ordering andcombination of process actions shown in the process flow diagramsdescribed herein is merely illustrative, and that using different oradditional process actions, or a different combination or ordering ofprocess actions can be used to enact the embodiments. The specificationand drawings are, accordingly, to be regarded in an illustrative ratherthan restrictive sense.

It should also be noted that the present invention can be implemented ina variety of computer systems. The various techniques described hereincan be implemented in hardware or software, or a combination of both.Preferably, the techniques are implemented in computer programsexecuting on programmable computers that each include a processor, astorage medium readable by the processor (including volatile andnon-volatile memory and/or storage elements), at least one input device,and at least one output device. Program code is applied to data enteredusing the input device to perform the functions described above and togenerate output information. The output information is applied to one ormore output devices. Each program is preferably implemented in a highlevel procedural or object oriented programming language to communicatewith a computer system. However, the programs can be implemented inassembly or machine language, if desired. In any case, the language canbe a compiled or interpreted language. Each such computer program ispreferably stored on a storage medium or device (e.g., ROM or magneticdisk) that is readable by a general or special purpose programmablecomputer for configuring and operating the computer when the storagemedium or device is read by the computer to perform the proceduresdescribed above. The system can also be considered to be implemented asa computer-readable storage medium, configured with a computer program,where the storage medium so configured causes a computer to operate in aspecific and predefined manner. Further, the storage elements of theexemplary computing applications can be relational or sequential (flatfile) type computing databases that are capable of storing data invarious combinations and configurations.

FIG. 12 is a flow diagram that illustrates a method for performing thedisclosed techniques, but it should be understood that the techniquesdescribed herein with respect to the remaining figures similarly capturethe methods available using the disclosed techniques. As illustrated inFIG. 12, a JVET encoder or decoder, such as those described in FIGS. 7,9, and 13, may receive a bitstream at 1202 indicating how a coding treeunit was partitioned in to coding units, such as a bitstream with asyntax structure as described with respect to FIG. 3. At 1210, theencoder or decoder may select an intra direction for a coding unit, suchas described with respect to FIG. 5, where a first intra direction modemay have a corresponding second intra direction mode that is weighted.At 1206, the encoder or decoder may generate a predictor for a firstintra direction mode and at 1208 the encoder or decoder may generate apredictor for the second intra direction mode, with a weighting factorapplied to the predicted pixels. At 1210, the coding unit may be codedwith a selected first and/or second intra direction mode.

FIG. 13 is a high level view of a source device 12 and destinationdevice 10 that may incorporate features of the systems and devicesdescribed herein. As shown in FIG. 13, example video coding system 10includes a source device 12 and a destination device 14 where, in thisexample, the source device 12 generates encoded video data. Accordingly,source device 12 may be referred to as a video encoding device.Destination device 14 may decode the encoded video data generated bysource device 12. Accordingly, destination device 14 may be referred toas a video decoding device. Source device 12 and destination device 14may be examples of video coding devices.

Destination device 14 may receive encoded video data from source device12 via a channel 16. Channel 16 may comprise a type of medium or devicecapable of moving the encoded video data from source device 12 todestination device 14. In one example, channel 16 may comprise acommunication medium that enables source device 12 to transmit encodedvideo data directly to destination device 14 in real-time.

In this example, source device 12 may modulate the encoded video dataaccording to a communication standard, such as a wireless communicationprotocol, and may transmit the modulated video data to destinationdevice 14. The communication medium may comprise a wireless or wiredcommunication medium, such as a radio frequency (RF) spectrum or one ormore physical transmission lines. The communication medium may form partof a packet-based network, such as a local area network, a wide-areanetwork, or a global network such as the Internet. The communicationmedium may include routers, switches, base stations, or other equipmentthat facilitates communication from source device 12 to destinationdevice 14. In another example, channel 16 may correspond to a storagemedium that stores the encoded video data generated by source device 12.

In the example of FIG. 13, source device 12 includes a video source 18,video encoder 20, and an output interface 22. In some cases, outputinterface 28 may include a modulator/demodulator (modem) and/or atransmitter. In source device 12, video source 18 may include a sourcesuch as a video capture device, e.g., a video camera, a video archivecontaining previously captured video data, a video feed interface toreceive video data from a video content provider, and/or a computergraphics system for generating video data, or a combination of suchsources.

Video encoder 20 may encode the captured, pre-captured, orcomputer-generated video data. An input image may be received by thevideo encoder 20 and stored in the input frame memory 21. The generalpurpose processor 23 may load information from here and performencoding. The program for driving the general purpose processor may beloaded from a storage device, such as the example memory modulesdepicted in FIG. 13. The general purpose processor may use processingmemory 22 to perform the encoding, and the output of the encodinginformation by the general processor may be stored in a buffer, such asoutput buffer 26.

The video encoder 20 may include a resampling module 25 which may beconfigured to code (e.g., encode) video data in a scalable video codingscheme that defines at least one base layer and at least one enhancementlayer. Resampling module 25 may resample at least some video data aspart of an encoding process, wherein resampling may be performed in anadaptive manner using resampling filters.

The encoded video data, e.g., a coded bit stream, may be transmitteddirectly to destination device 14 via output interface 28 of sourcedevice 12. In the example of FIG. 13, destination device 14 includes aninput interface 38, a video decoder 30, and a display device 32. In somecases, input interface 28 may include a receiver and/or a modem. Inputinterface 38 of destination device 14 receives encoded video data overchannel 16. The encoded video data may include a variety of syntaxelements generated by video encoder 20 that represent the video data.Such syntax elements may be included with the encoded video datatransmitted on a communication medium, stored on a storage medium, orstored a file server.

The encoded video data may also be stored onto a storage medium or afile server for later access by destination device 14 for decodingand/or playback. For example, the coded bitstream may be temporarilystored in the input buffer 31, then loaded in to the general purposeprocessor 33. The program for driving the general purpose processor maybe loaded from a storage device or memory. The general purpose processormay use a process memory 32 to perform the decoding. The video decoder30 may also include a resampling module 35 similar to the resamplingmodule 25 employed in the video encoder 20.

FIG. 13 depicts the resampling module 35 separately from the generalpurpose processor 33, but it would be appreciated by one of skill in theart that the resampling function may be performed by a program executedby the general purpose processor, and the processing in the videoencoder may be accomplished using one or more processors. The decodedimage(s) may be stored in the output frame buffer 36 and then sent outto the input interface 38.

Display device 38 may be integrated with or may be external todestination device 14. In some examples, destination device 14 mayinclude an integrated display device and may also be configured tointerface with an external display device. In other examples,destination device 14 may be a display device. In general, displaydevice 38 displays the decoded video data to a user.

Video encoder 20 and video decoder 30 may operate according to a videocompression standard. ITU-T VCEG (Q6/16) and ISO/IEC 1VIPEG (JTC 1/SC29/WG 11) are studying the potential need for standardization of futurevideo coding technology with a compression capability that significantlyexceeds that of the current High Efficiency Video Coding HEVC standard(including its current extensions and near-term extensions for screencontent coding and high-dynamic-range coding). The groups are workingtogether on this exploration activity in a joint collaboration effortknown as the Joint Video Exploration Team (WET) to evaluate compressiontechnology designs proposed by their experts in this area. A recentcapture of JVET development is described in the “Algorithm Descriptionof Joint Exploration Test Model 5 (JEM 5)”, JVET-E1001-V2, authored byJ. Chen, E. Alshina, G. Sullivan, J. Ohm, J. Boyce.

Additionally or alternatively, video encoder 20 and video decoder 30 mayoperate according to other proprietary or industry standards thatfunction with the disclosed JVET features. Thus, other standards such asthe ITU-T H.264 standard, alternatively referred to as MPEG-4, Part 10,Advanced Video Coding (AVC), or extensions of such standards. Thus,while newly developed for JVET, techniques of this disclosure are notlimited to any particular coding standard or technique. Other examplesof video compression standards and techniques include MPEG-2, ITU-TH.263 and proprietary or open source compression formats and relatedformats.

Video encoder 20 and video decoder 30 may be implemented in hardware,software, firmware or any combination thereof. For example, the videoencoder 20 and decoder 30 may employ one or more processors, digitalsignal processors (DSPs), application specific integrated circuits(ASICs), field programmable gate arrays (FPGAs), discrete logic, or anycombinations thereof. When the video encoder 20 and decoder 30 areimplemented partially in software, a device may store instructions forthe software in a suitable, non-transitory computer-readable storagemedium and may execute the instructions in hardware using one or moreprocessors to perform the techniques of this disclosure. Each of videoencoder 20 and video decoder 30 may be included in one or more encodersor decoders, either of which may be integrated as part of a combinedencoder/decoder (CODEC) in a respective device.

Aspects of the subject matter described herein may be described in thegeneral context of computer-executable instructions, such as programmodules, being executed by a computer, such as the general purposeprocessors 23 and 33 described above. Generally, program modules includeroutines, programs, objects, components, data structures, and so forth,which perform particular tasks or implement particular abstract datatypes. Aspects of the subject matter described herein may also bepracticed in distributed computing environments where tasks areperformed by remote processing devices that are linked through acommunications network. In a distributed computing environment, programmodules may be located in both local and remote computer storage mediaincluding memory storage devices.

Examples of memory include random access memory (RAM), read only memory(ROM), or both. Memory may store instructions, such as source code orbinary code, for performing the techniques described above. Memory mayalso be used for storing variables or other intermediate informationduring execution of instructions to be executed by a processor, such asprocessor 23 and 33.

A storage device may also store instructions, instructions, such assource code or binary code, for performing the techniques describedabove. A storage device may additionally store data used and manipulatedby the computer processor. For example, a storage device in a videoencoder 20 or a video decoder 30 may be a database that is accessed bycomputer system 23 or 33. Other examples of storage device includerandom access memory (RAM), read only memory (ROM), a hard drive, amagnetic disk, an optical disk, a CD-ROM, a DVD, a flash memory, a USBmemory card, or any other medium from which a computer can read.

A memory or storage device may be an example of a non-transitorycomputer-readable storage medium for use by or in connection with thevideo encoder and/or decoder. The non-transitory computer-readablestorage medium contains instructions for controlling a computer systemto be configured to perform functions described by particularembodiments. The instructions, when executed by one or more computerprocessors, may be configured to perform that which is described inparticular embodiments.

Also, it is noted that some embodiments have been described as a processwhich can be depicted as a flow diagram or block diagram. Although eachmay describe the operations as a sequential process, many of theoperations can be performed in parallel or concurrently. In addition,the order of the operations may be rearranged. A process may haveadditional steps not included in the figures.

Particular embodiments may be implemented in a non-transitorycomputer-readable storage medium for use by or in connection with theinstruction execution system, apparatus, system, or machine. Thecomputer-readable storage medium contains instructions for controlling acomputer system to perform a method described by particular embodiments.The computer system may include one or more computing devices. Theinstructions, when executed by one or more computer processors, may beconfigured to perform that which is described in particular embodiments.

As used in the description herein and throughout the claims that follow,“a”, “an”, and “the” includes plural references unless the contextclearly dictates otherwise. Also, as used in the description herein andthroughout the claims that follow, the meaning of “in” includes “in” and“on” unless the context clearly dictates otherwise.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.

Although embodiments have been disclosed herein in detail and inlanguage specific to structural features and/or methodological actsabove, it is to be understood that those skilled in the art will readilyappreciate that many additional modifications are possible in theexemplary embodiments without materially departing from the novelteachings and advantages of the invention. Moreover, it is to beunderstood that the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Accordingly, these and all such modifications are intended to beincluded within the scope of this invention construed in breadth andscope in accordance with the appended claims.

We claim:
 1. An apparatus for decoding video data comprising one or moreprocessors configured to: (a) receive a bitstream indicating how acoding tree unit was partitioned into coding units according to apartitioning structure that allows nodes to be split according to apartitioning technique; (b) parse said bitstream to identify a syntaxelement indicating an intra direction mode to use for generating atleast one predictor; (c) wherein the intra direction mode is a firstintra direction mode in a plurality of intra direction modes thatincludes at least one weighted intra direction mode that corresponds toa non-weighted intra direction mode; (d) identify from the syntaxelement whether to use a non-weighted or weighted intra direction modeto generate the at least one predictor; (e) generate the at least onepredictor using the intra direction mode; and (f) decoding said codingunit in accordance with the at least one generated predictor associatedwith the selected intra direction mode.